Hello codeforces,
The past two rounds (Goodbye 2022, Hello 2023) had quite a lot of participants, which is great, but comes with the downside of a very long loading time for the website at the beginning of the contest, reaching 5 minutes in "Hello 2023" for me personally.
This kind of delay is annoying in general, but especially during the critical first few minutes of the contest where wasting time on problem A is costly.
Now, the obvious solution would be adding additional resources to the server during peak times, but there's only one* big burst of requests and submissions and it cools down pretty fast, so in any case a method to move some of the load on the server to a different time would be very helpful.
My suggestion is publishing the problemset in advance, even 30 minutes before the start, encrypted. Then, at the start of the contest the encryption key would be broadcasted to everyone, letting them decrypt the relatively heavy statements on their own, and eliminating the cost of serving the full statements to every participant at the beginning of the round.
In terms of implementing this scheme, the contest page should be as light-weight as possible, it's only functionality being receiving the encrypted statements (or already coming with them) and waiting for the key, and it should be available in advance. There can even be an option to download the encrypted problemset. Also, in general there should be a higher priority for serving everyone the problems than for accepting solutions / showing the scoreboard (which would be empty anyway).
I'm interested to know your thoughts on this suggestion and on the problem it describes in general, or if you can think of any alternatives/improvements. Is it realistic? Would it make a difference? You decide! anyways have a good rest of the day, happy coding!
* Coming to think of it, I had the same problem at the end of the last contest, and almost couldn't submit my solution in time. This second growth in activity can probably be attributed to everyone rushing to submit what they have or refreshing the scoreboard, so in that case the opitimization I described above wouldn't work of course, but I also think the main priority is receiving the last submissions from participants and if we're dealing with limited resources we can wait with evaluation / calculating the scoreboard / other less time-sensitive functionalities. what do you think? (we can even do the reverse of serving encrypted problems in advance, and accept hashes of submissions instead in the last couple of minutes, then allow users to pair their hashes with their actual code for some time after the round is over)
This is why I always start every contest recently with
m2.codeforces.com(m1 sometimes gets slow, m2 almost always works fast enough)Oh I thought those were only backup servers, but wouldn't they face the same problem if more people start using them? Is there any difference between them and the main website besides possibly a lighter webpage and no scoreboard?
they don't permit file submit (which for people like me who don't know how to use their computer is a big pain)
The lightweight pages don't save language/task choices, so basically you need to select again on every submission. And you can't submit files as already mentioned on the other comment. Didn't have any other inconveniences personally. (If you use file submission regularly it might be a bit inconvenient, but you can always copy paste from the IDE) The lightweight pages can get laggy (of course, traffic is limited), and sometimes it happens on m1, as I have experienced a few times before. They have made 3 lightweight pages for a reason, and you could consider using the pages with a larger number as a fallback (i.e. use m2 as a fallback for m1, use m3 as a fallback for m2. If all 3 lightweight pages get laggy, then that's probably an unrated-worthy issue)
Oh ok, I copy and paste from my IDE anyways so that shouldn't be a problem. thanks for the tip!
Then again, I was talking about the general problem that no amount of extra subdivisions into smaller servers would solve, the biggest percentage of capacity across all resources is no less than the total percentage of the total capacity.
I also always start on m2, and every time I have to wait almost a minute until latex loads in. Do you not face this issue?
Oh yes, latex loads quite slow on the lightweight pages, I felt that. For this the suggestion by the OP could help a lot, but we may face some issues if we are to really implement this on Codeforces. How will we guarantee that every participant will have the correct set of statements before the contest begins? Currently we don't particularly require that the participants be on the webpage 30 minutes before the contest begins, and we wouldn't be practically able to in any way. (unless we change our system to some TopCoder-like system, I guess?) I think the idea is helpful, it's just that it's a very hard thing to pursue.
You're correct in that this would be tricky to implement, but getting the problem statements in advance shouldn't be that big of a problem.
There's no need for a set time when everyone gets the statements at. The encrypted problemset will be re-sent to you every time you open the new hypothetical contest page, whether it be 30 or 5 minutes before the contest, then just like a message pops out when the round starts and redirects you to the first problem, it'll instead request the key and update the statements. Of course after the contest starts there should be an option for getting the problemset directly, so overall nothing will change except that we will give people who don't want get stuck in traffic the option to leave home early (great analogy xD).
Broadcasted in which way?
I faced that during Dytechlab Cup 2022. I finished my code literally 8 seconds before the end of the contest but loading of the "Submit code" page + sending a code itself took more then that, so I missed a whole problem because of this issue. After this incident I'm loading "Submit code" page in advance but it resolves half of a problem and the issue with submission delay in the very end is still there. One possible solution here would be to accept any code which was submitted before the end of the contest by client time (on a front-end side). That way time to reach the server will not affect last second submitters. There is some room for cheating here though (as always if you rely on data from client side), but we can add some hard deadline on the server side (e.g. 15 seconds after contest end) to deal with it.
Thanks for the feedback, and my condolences for your experience, there's nothing worse than not being able to submit the code you've finally got working in time.
Doesn't really matter, every user can request the key and that would still make a big difference
As for your second point, you can never trust the client, and that's why I suggested that at the last couple of minutes submitting code would instead automatically send the hash of the submission (which can't be faked), and then we could give the contestants even 5-10 minutes to submit their real code while everything cools down.
In the last contest I had two minutes of inaccessibility leading to the end, which partially went past it, so if the root of the problem lies with the large amount of traffic codeforces needs to handle at that specific moment, and the traffic will stay high as long as people can submit, the only way to solve it is by finding a more efficient way for receiving and authenticating submissions.
Absolutely. Thanks!
Actually, it does matter a lot. Because if the main bottleneck is the number of requests and the size of response is not that important — we will not get much from this change while requests are processed in the same way. And the reason why I asked is that you mentioned "broadcasting", which actually can be done more efficiently then processing regular requests. So I wanted to double check if you hadn't in mind some of these efficient methods.
Oh, initially I didn't get that hashing would be done automatically on the client side. If "pairing" also would be done automatically (e.g. with next request right after sending the hash) — then users wouldn't be burdened by additional functionality and there would be no hand job in submission process. That way it make a lot of sense! And if we would combine that with reserving some resources just for receiving these hashes (to not be affected by other types of requests like scoreboard refresh, problem opening or even receiving full version of codes) — it could be a good solution to a last seconds submission problem!
Well as far as I know broadcasting isn't something you do outside of your LAN, but my initial intention was indeed a multicast of some sort, though I'm not very familiar with usage of the concept.
But surely sending a couple of bytes instead of thousands for every request would make a difference, don't you think? aren't the responses to all of the requests larger than the requests themselves in all aspects?
That's partially true in IP terminology but I'm talking in general. Anyways, I think we understood each other.
Yeah, I agree that it would make a difference. But the real question is "what's the bottleneck?". And if it's amount of traffic — indeed, your suggestion itself would be a game changer. But if the real bottleneck is something dependent more on number of simultaneous requests and only secondarily on amount of traffic (e.g. number of simultaneous connections to DB) — then, decreasing amount of traffic itself may be not enough.
Red Star: How about the idea "we don't care about buzzerbeater" ?
My idea is adding the rule "Participants can submit their code normally, at 5min before the contest" is needed to end a contest.
With this rule, we can guarantee the smooth server 5min before contest ends, and we don't have to care about the last minutes submit rushes.
BTW I recall about FHC testcases(download time isn't counted as execution time) and some puzzle competitions, by hearing the main idea.
I'm really sorry, but I don't understand the rule/idea you described. could you please clarify what you mean? "Participants can submit their code normally, at 5min before the contest" — isn't that already the case? or are you saying that only submissions that are at least 5 minutes before the end should be guaranteed to be received and evaluated?
Also about your second point, the problem I'm describing isn't related to the evaluation itself, rather it sometimes being impossible to submit, but I might have missed your point entirely :')
I meant the site should receive our solution finely and smoothly 5min before contest ends(but not necessary to guarantee to receive feedback during contest).
I got an inspiration from JOI rule (it's guaranteed to get feedbacks during the contest, for submissions which made until 15min before the competition ends (and if it becomes impossible, the competition will be extended)), and it's an application about the submission issue.
Oh ok, in that case I agree, that's what I meant in "the main priority is receiving the last submissions from participants [...] we can wait with evaluation". but I'm not sure whether a constant submission-only period is preferable, because I don't know how much evaluation affects the ability of the server to receive submissions, compared to the effect of high traffic (like a lot of participants requesting the scoreboard page / submitting solutions).